ETSITS132 111-2V3.2.0 



(2000-09) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

Telecommunication Management; 

Fault Management; 
Part 2: Alarm Integration Reference Point: Information Service 

(3GPP TS 32.111-2 version 3.2.0 Release 1999) 



3Si^ 




3GPP TS 32.111-2 version 3.2.0 Release 1999 1 ETSI TS 132 111-2 V3.2.0 (2000-09) 



Reference 



RTS/TSGS-0532111 -2UR 
Keywords 



UMTS 



ETSI 

650 Route des Lucioles 
F-Q6921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N°348 623 562 00017 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 
Information on the current status of this and other ETSI documents is available at http://www.etsi.orq/tb/status/ 

If you find errors in the present document, send your comment to: 
editor@etsi.fr 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2000. 
All rights reserved. 



ETSI 



3GPP TS 32.111-2 version 3.2.0 Release 1999 2 ETSI TS 132 111-2 V3.2.0 (2000-09) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 3 14 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by the ETSI 3"^^ Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI dehverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/key . 



ETSI 



3GPP TS 32.111-2 version 3.2.0 Release 1999 3 ETSI TS 132 111-2 V3.2.0 (2000-09) 



Contents 



Foreword 4 

Introduction 4 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 7 

4 Basic aspects 8 

4.1 Background 8 

4.2 System Overview 8 

5 IRP Information Service 9 

5.1 Interfaces 9 

5.2 Operations of AlarmlRPOperations Interface 9 

5.2.1 Operation acknowledge Alarms (M) 9 

5.2.2 Operation unacknowledgeAlarms (O) 10 

5.2.3 Operation getAlarmList (M) 11 

5.2.4 Operation getAlarmCount (O) 11 

5.2.5 Operation get AlarmlRP Vers ion (M) 12 

5.3 Notifications of AlarmlRPNoti float ions Interface 12 

5.3.1 General 12 

5.3.2 Notification not IfyNewAlarm (M) 12 

5.3.3 Notification notifyChangedAlarm (O) 13 

5.3.4 Notification not IfyAckSt at eChanged (M) 13 

5.3.5 Notification notifyClearedAlarm (M) 13 

5.3.6 Notification not IfyAlarmLl St Rebuilt (M) 14 

5.4 Behaviour 14 

5.4.1 Alarm List 14 

5.4.2 Network Resource Name 14 

5.4.3 Alarm Information Identification 15 

5.4.3.1 Use of alarmlnf ormationRef erence 15 

5.4.4 Alarm loss detection and recovery 15 

5.4.5 Alarm List loss 15 

5.4.6 Alarm Information 15 

6 Dynamic Model 18 

6.1 Alarm states 18 

Annex A (normative): Event Types and Extended Event Types 19 

Annex B (normative): Probable Causes 20 

Annex C (informative): Examples Use of notifyChangedAlarm 25 

Annex D (normative): Mapping of Alarm Information Reference to its Solution Set 

Equivalents 27 

D.l Matching-Criteria- Attributes 28 

Annex E (informative): Change history 29 



ETSI 



3GPP TS 32.111-2 version 3.2.0 Release 1999 4 ETSI TS 132 111-2 V3.2.0 (2000-09) 



Foreword 



This Technical Specification (TS) has been produced by the 3^^ Generation Partnership Project (3 GPP). 

The present document is part 2 of a multi-part TS covering the 3^^ Generation Partnership Project: Technical 
Specification Group Services and System Aspects, as identified below: 

Part 1 : "3G Fault Management Requirements"; 

Part 2: "Alarm Integration Reference Point: Information Service"; 

Part 3: "Alarm Integration Reference Point: CORB A Solution Set Version 1:1; 

Part 4: "Alarm Integration Reference Point: CMIP Solution Set". 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document is part of a set of TSs which describe the requirements and information model necessary for the 
Telecommunication Management (TM) of 3G systems. The TM principles and TM architecture are specified in 
3GPP TS 32.101 [12] and 3GPP TS 32.102 [13]. 

A 3G system is composed of a multitude of Network Elements (NE) of various types and, typically, different vendors 
inter-operate in a co-ordinated manner in order to satisfy the network users' communication requirements. 
The occurrence of failures in a NE may cause a deterioration of this NE's function and/or service quality and will, in 
severe cases, lead to the complete unavailability of the NE. In order to minimise the effects of such failures on the 
Quality Of Service (QOS) as perceived by the network users it is necessary to: 

• detect failures in the network as soon as they occur and alert the operating personnel as fast as possible; 

• isolate the failures (autonomously or through operator intervention), i.e. switch off faulty units and, if applicable, 
limit the effect of the failure as much as possible by reconfiguration of the faulty NE/adjacent NEs; 

• if necessary, determine the cause of the failure using diagnosis and test routines; and, 

• repair/eliminate failures in due time through the application of maintenance procedures. 

This aspect of the management environment is termed "Fault Management" (EM). The purpose of EM is to detect 
failures as soon as they occur and to limit their effects on the network Quality of Service (QOS) as far as possible. 
The latter is achieved by bringing additional/redundant equipment into operation, reconfiguring existing 
equipment/NEs, or by repairing/eliminating the cause of the failure. 
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Fault Management (FM) encompasses all of the above functionalities except commissioning/decommissioning of NEs 
and potential operator triggered reconfiguration (these are a matter of Configuration Management (CM), cf. 
3GPPTS 32.106 [1]). 

FM also includes associated features in the Operations System (OS), such as the administration of a pending alarms list, 
the presentation of operational state information of physical and logical devices/resources/functions, and the provision 
and analysis of the alarm and state history of the network. 
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1 Scope 



The present document (3GPP TS 32.111 Part-2) defines the Alarm Integration Reference Point (IRP) Information 
Service (IS), which addresses the alarm surveillance aspects of Fault Management (FM), applied to the N Interface 
between EM-NM and NE-NM. 

The purpose of the Alarm IRP is to define an interface through which a "system" (typically a Network Element 
Manager or a Network Element) can communicate alarm information for its managed objects to one or several Manager 
Systems (typically Network Management Systems). 

The Alarm IRP IS defines the semantics of alarms and the interactions visible across the reference point in a protocol 
neutral way. It defines the semantics of the operations and notifications visible in the IRP. It does not define the syntax 
or encoding of the operations, notifications and their parameters. 



References 



The following documents contain provisions, which through reference in this text constitute provisions of the present 
document. References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 



• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 



[I] ITU-T Recommendation Q821: "Stage 2 and Stage 3 description for the Q3 interface - Alarm 
surveillance". 

[2] ITU-T Recommendation X.733 (02/92): "Information technology - Open Systems Interconnection 
- Systems management: Alarm Reporting Function". 

[3] ITU-T Recommendation X.721: "Information Technology - Open Systems Interconnection - 
Structure Of Management Information: Definition Of Management Information". 

[4] ITU-T Recommendation X.736: "Security Alarm Reporting Function". 

[5] ITU-T Recommendation X.732: "Relationship Management Function". 

[6] ITU-T Recommendation X.73 1 : "State Management Function". 

[7 ] ITU-T Recommendation X . 7 3 : ' 'Obj ect Management Function' ' . 

[8] ITU-T Recommendation X.720: "Management Information Model". 

[9] ITU-T Recommendation M.3100 (07/95): "Generic network information model". 

[10] GSM 12.11 version 6.2.0 Release 1997: "Fault management of the Base Station System (BSS)". 

[II] 3GPP TS 32. 106-2: "Notification IRP: Information Service". 

[12] 3GPP TS 32. 101 : "3G Telecom Management principles and high level requirements". 

[13] 3GPP TS 32.102: "3G Telecom Management architecture". 

[14] 3GPP TS 32.106-8: "Name Convention for Managed Objects". 

[15] 3GPP TS 32.111-1: "3G Fault Management". 

[16] 3GPP TS 32.111-3: "Alarm Integration Reference Point: CORBA Solution Set Version 1:1". 

[17] 3GPP TS 32. 111-4: "Alarm Integration Reference Point: CMIP Solution Set". 
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Definitions and abbreviations 



3.1 Definitions 

In addition to the terms and definitions defined in 3GPP TS 32.111-1 [15], the following definitions apply to this 
document: 

Acknowledge alarm: It is functionality provided to facilitate the management of alarms. The definition of the practical 
activity associated to the alarm acknowledgement is outside the scope of this IRP. The alarm acknowledgement process 
is summarised as follows: 

IRP Agent, when first reports an alarm to IRPManager, will set the alarm's Acknowledgement State to 
unacknowledged. IRPManager, on behalf of the user (e.g. operator), can set the state to acknowledged by 
supplying (a) identifier of user acknowledging the alarm and (b) identifier of management system on which 
IRPManager runs. IRP Agent records the two pieces of information and the time of acknowledgement in Alarm 
Information of Alarm List. IRPManager representing a human operator can initiate acknowledge alarm request. 
IRPManager, representing an authorized management application, can initiate acknowledge alarm request as well. 

Alarm List: It contains a list of Alarm Information whose severity level is not Cleared, or severity level is Cleared 
but is not yet Acknowledged. IRP Agent maintains the Alarm List. 

Correlated Notifications: It contains a set of Notification identifiers. It may be present as a parameter of Notification. 
If present, the set of Notifications identified by Correlated Notifications and the subject Notification are related 
(correlated). 

Event: It is an occurrence that is of significance to network operators, the NEs under surveillance and Network 
Management applications. Events do not have state. 

IRPManager: defined in 3GPP TS 32.102 [13]. 

Notification: It refers to the transport of events from IRP Agent to IRPManager. In this IRP, notification is used to 
carry alarm information from IRP Agent to IRPManager. 

Notification Identifier: It provides an identifier for the notification, which may be carried in the Correlated 
Notifications parameter (see below) of future notifications. Notification identifiers shall be chosen to be unique across 
all notifications of a particular managed object (representing the NE) throughout the time that correlation is significant. 
Notification carries this identifier in parameter called not i float ionld. The algorithm by which correlation is 
accomplished is outside the scope of this IRP. 

IRPAgent: defined in 3GPP TS 32.102 [13]. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AIR Alarm Information Reference 

CCITT The International Telegraph and Telephone Consultative Committee 

CMIP Common Management Information Protocol 

EM Element Manager 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

M Mandatory 

MO Managed Object 

MOC Managed Object Class 

MOI Managed Object Instance 

NE Network Element 

NM Network Manager 

NMC Network Management Centre 

O Optional 
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OS 
OSI 

ss 

UML 



Operations System 

Open System Interconnection 

Solution Set 

Unified Modeling Language 



4 Basic aspects 
4.1 Background 

Integration Reference Points (IRPs) are the means within 3G Telecom Management (TM) for specifying interoperable 
points of information exchange between systems and applications. 

3GPP TS 32.101 [12] and 32.102 [13] contain background and introductory information about IRP. 



4.2 System Overview 



The following figures identify system contexts of this IRP in terms of implementations called IRP Agent and 
IRPManager. 

"IRPManager" depicts a process that interacts with IRP Agent for the purpose of receiving alarms via this IRP. 

Examples of IRPManagers can be Network Management Systems and Alarm viewing devices (such as a local craft 

terminal). IRP Agent implements and supports the Alarm IRP. 

IRP Agent can be one Network Element (NE) (see figure 2) or it can be one Element Manager (EM) with one or more 

NEs (see figure 1). In the latter case, the interfaces (represented by a thick dotted line) between the EM and the NEs are 

not subject of this IRP. Whether EM and NE share the same hardware system is not relevant to this IRP either. 

By observing the interaction across the Alarm IRP, one cannot deduce if EM and NE are integrated in a single system 

or if they run in separate systems. 

As indicated in figure 1 and figure 2, the subject IRP need to be complemented with the Notification IRP 

3GPP TS 32.106-2 [11] (to allow IRPManager to subscribe to notifications issued by IRP Agent) and (optionally) 

product-specific resource models describing the MOs maintained by IRP Agent. 









1 
1 














IRPManager 






IRPAgent 






NEs 




1 
1 






NM 
















1 




FM 





Itf-N 




Notification IRP 
Alarm IRP 



Figure 1 : System Context A 
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Figure 2: System Context B 
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IRP Information Service 



5.1 



Interfaces 



Figure 3 illustrates the operations and notifications defined as interfaces implemented and used by IRP Agent and 
IRPManager. In this document the word "interface" is used to convey identical meaning as that defined within UML. 
Parameters and return status are not indicated. 

Two interfaces are defined. One is called AlarmlRPOpe rat ions. This interface defines operations implemented 
by IRP Agent and used (or called by) IRPManager. The other is called AlarmlRPNotification. This interface 
defines notification implemented by IRPManager and used by IRP Agent. 




«lnterface» 
AlarmlRPOperations 



macknowledgeAlarmsO 

munacknowledgeAlarmsO 

HgetAlarmListQ 

dgetAlarmlRPVersionQ 

mgetAlarmCountO 



«lnterface» 
AlarmlRPNotifications 




I 



|notifyNewAlarm() 
jnotifyChangedAlarm () 
jnotifyAlarmListRebuiltO 
jnotifyAckStateChangedO 
jnotifyClearedAlarmO 



Figure 3: Operations and Notification 



5.2 Operations of AiarmiRPOperations Interface 

5.2.1 Operation acknowledgeAlarms (M) 

IRPManager invokes this operation to acknowledge one or more alarms. IRPManager does not supply time of 
acknowledgement. If operation is successful, IRP Agent registers the time of operation in ackTime in Alarm 
Information in Alarm List. IRP Agent registers ackUserld and ackSystemldin Alarm Information. It sets 
ackState to "acknowledged" as well. 

The ackTime, ackUserld, ackSystemId and ackState are collectively called Acknowledgement Information 
in the present document. 

IRP Agent shall send notifications about Acknowledgement Information to all IRPManagers in subscriptions. 

IRP Agent shall remove the Alarm Information whose perceivedSeverity is cleared and its Acknowledgement 

State is "acknowledged'' from Alarm List. 
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Tablel : Parameters for acknowiedgeAiarms 



Name 


Qualifier 


Purpose 


alarm 

InformationR 

eferenceList 


Input, M 


It carries one or more identifiers identifying Alarm Information in Alarm List. Each 
identifier identifies at most one Alarm Information in Alarm List. 


AckUserld 


Input, M 


It identities the user acknowledging the alarm. It can be used to identify the human 
operator such as "John Smith" or it can identify a group, such as "Team Six". It may 
contain no information implying that IRPManager does not wish this information be 
kept in Alarm Information in Alarm List. 


ackSystemId 


Input, 


It identifies the processing system on which the subject IRPManager runs. It may 
contain no information implying that IRPManager does not wish this information be 
kept in Alarm Information in Alarm List. 


badAlarmlnfo 
rmat i onRe f e r 
enceList 


Output, M 


It identifies the Alarm Information that are not present in Alarm List or that they are 
present, but Acknowledgement Information has not changed, in contrast to 
IRPManager' s request. Element of this Hst is a pair of Alarm Information Reference 
and reason. This parameter shall contain at least one element in case the output 
status indicates partial failure. Otherwise, it shall contain no information. 


status 


Output, M 


(a) Operation succeeded. Acknowledgement St ate of all Alarm Information (in 
Alarm List) identified by alarmlnf ormationRef erenceList are 
"acknowledged" or 

(b) Operation failed. No change is made to Acknowledgement Information in any 
Alarm Information in Alarm List. Example of one such failure is when parameter 
alarmlnf ormationRef erenceList contains no identifier or no valid identifier 
or 

(c) Operation partially failed. It indicates that at least one but not all Alarm 
Information (in Alarm List) identified by parameter 

alarmlnf ormationRef erenceList has changed its Acknowledgement 
Information according to IRPManager' s request. In this case, the output parameter, 
called badAlarmInf ormationRef erenceList, shall contain a subset of the 
identifiers carried in parameter alarmlnf ormationRef erenceList. 



5.2.2 Operation unacknowledgeAlarms (O) 

IRPManager invokes this operation to unacknowledge one or more alarms. 

If operation is successful, IRP Agent shall remove all Acknowledgement Information in Alarm Information in Alarm 
List. It shall send notifications carrying Acknowledgement Information to all IRPManagers (including the subject 
IRPManager) in subscriptions. The Acknowledgement Information carried shall contain ackUserld, ackTime and 
ackState. In addition it may contain ackSystemld. 

Table 2: Parameters for unacknowledgeAlarms 



Name 


Qualifier 


Purpose 


alarm 

In format ionRefe 

renceList 


Input, M 


It carries one or more identifiers identifying Alarm Information in Alarm List. 
Each identifier identifies at most one Alarm Information in Alarm List. 


ackUserld 


Input, M 


It identities the user un-acknowledging the alarm. 


ackSystemld 


Input, 


It identifies the processing system on which the subject IRPManager runs. 


badAlarmInf orma 
tionReferenceLi 

St 


Output, M 


It identifies the Alarm Information that are not present in Alarm List or that they 
are present, but Acknowledgement Information has not changed, in contrast to 
IRPManager' s request. Element of this list is a pair of Alarm Information 
Reference and reason. This parameter shall contain at least one element in case 
the output status indicates partial failure. Otherwise, it shall contain no 
information. 


status 


Output, M 


(a) Operation succeeded. Acknowledgement State of the Alarm 
Information (in Alarm List) identified by 

alarmlnf ormationRef erenceList is "unacknowledged'' or 

(b) Operation failed. No change is made to Acknowledgement Information in 
any Alarm Information in Alarm List. Failure examples are (a) when parameter 
alarmlnf ormationRef erenceList contains no identifier (b) it contains 
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no valid identifier (c) its ackUserld and ackSystemlddo not correspond 

to ones used in previous acknowledgeAlarms operation. 

(c) Operation partially failed. It indicates that at least one but not all Alarm 

Information (in Alarm List) identified by parameter 

alarmlnf ormationRef erenceList has changed its Acknowledgement 

Information according to IRPManager's request. In this case, the output 

parameter, called badAlarmInf ormationRef erenceList, shall contain a 

subset of the identifiers carried in parameter 

alarmlnf ormationRef erenceList. 



5.2.3 Operation getAlarmList (M) 

IRPManager requests IRP Agent to provide a list of alarms in Alarm List. These alarms can be provided as a sequence 
of single alarm notifications (asynchronous alarm alignment) or in a unique message containing all the alarms 
(synchronous alarm alignment). 

Table 3: Parameters of getAlarmList 



Name 


Qualifier 


Purpose 


alarmlnform 
ationList 


Output, M 


It carries Alarm Information in Alarm List. Implementation of this parameter is SS 
dependent. 


alarmAckSta 
te 


Input, 


It has five values indicating a) all alarms b) all active alarms c) all active and 
acknowledged alarms d) all active and un-acknowledged alarms e) all cleared and un- 
acknowledged alarms. 

If present, IRP Agent shall use it to apply on Alarm Information in Alarm List when 
constructing its output parameter alarmlnf ormationList. If input parameter 
filter is also present, the filter constraint carried in filter shall also be applied as 
well. 

If absent, IRP Agent shall return all Alarm Information in Alarm List subject to filter 
constraint expressed in filter parameter. 


filter 


Input, 


It carries a filter constraint. IRP Agent shall return Alarm Information that satisfies this 
filter constraint only. Filter constraint grammar is SS dependent. 
If parameter is absent and the alarm alignment is asynchronous, IRP Agent shall apply 
the current filter constraint used towards the IRPManager. 


status 


Output, M 


(a) Operation succeeded in that alarmlnf ormat ionLi st contains the required 
Alarm Information 

or 

(b) Operation failed because of specified or unspecified reason. 



5.2.4 Operation getAlarmCount (O) 

IRPManager wishes to know the amount of Alarm Information kept in IRP Agent. IRPManager requests IRP Agent to 
provide the counts via this operation. Possible usage is for IRPManager to find out the number of Alarm Information in 
Alarm List before invoking getAlarmList operation. 

Table 4: Parameters for getAlarmCount 



Name 


Qualifier 


Purpose 


filter 


Input, 


It carries a filter constraint. IRP Agent shall return Alarm Information that 
satisfies this filter constraint only. Filter constraint grammar is SS dependent. 


alarmAckState 


Input, 


It has five values indicating a) all alarms b) all active alarms c) all active and 
acknowledged alarms d) all active and un-acknowledged alarms e) all cleared 
and un-acknowledged alarms. 

If present, IRP Agent shall apply it for counting. If input parameter filter 
is also present, IRP Agent shall apply the filter constraint for counting as well. 
If absent, IRP Agent shall count all Alarm Information, subject to filter 
constraint expressed in filter parameter. 


criticalCount, 
ma jorCount, 
minorCount, 
warningCount, 


Output, M 


They specify the number of Alarm Information whose perceived 
severity are critical, major, minor, warning, 
indeterminate and Cleared respectively. 
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indeterminateCoun 
t, clearedCount 






status 


Output, M 


(a) Operation succeeded in that the counts returned are vaHd 
or 

(b) Operation failed because of specified or unspecified reason. 



5.2.5 Operation getAlarmlRPVersion (M) 

IRPManager wishes to determine the IRP versions supported by the IRP Agent. IRP Agent shall return with a list of (one 
or more) version numbers currently supported. 



Table 5: Parameters of getAiarmiRPVersion 



Name 


Qualifier 


Purpose 


versionNumbe 
rList 


Output, M 


It indicates one or more SS version numbers supported by the IRP Agent. 


status 


Output, M 


(a) Operation succeeded in that IRP Agent is able to provide the list of version 
numbers. 

(b) Operation failed in that the IRP Agent is not able to provide the list of supported 
version numbers. 



5.3 



Notifications of AiarmiRPNotifications Interface 



5.3.1 General 

Operations that IRPManager uses to manage subscription to receive notifications are specified in Notification IRP 
(3GPP TS 32.106-2 [11]). 3GPP TS 32.106-2 [11] also specifies a generic notification notify. 3GPP TS 32.106-2 
[11] defines a number of parameter-attributes that are commonly carried in notifications as well. 

The conmionly carried parameter-attributes are collectively called not if icat ionHeader in the present document. 
The parameter-attribute names and their qualifiers are listed in table 6. 

Table 6: Notification Header 



Parameter-Attributes defined in 3GPP TS 32.106-2 [11] 


Quaiifier for use in this iS 


managedObjectClass 


M 


managedObject Instance 


M 


notif icationid 


M 


eventTime 


M 


systemDN 


C 


eventType 


M 


extendedEventType 


M 



The following subclauses define specific notifications relevant for Alarm IRP by extending notify in 
3GPPTS 32.106-2 [11]. 

5.3.2 Notification notifyNewAlarm (M) 

IRP Agent notifies the subscribed IRPManager that a new alarm has been added into the 5.4.1 Alarm List and that the 
added alarm satisfies the current filter constraint of the subscription. 

Table 7: Parameters of notifyNewAlarm 



Name 


Qualifier 


Comment 


notif icat ionHeader 


Input, M 


See Table 6: Notification Header, 


alarmlnformationBody 


Input, M 


It contains information about the new alarm. 
See subclause 5.4.6 Alarm Information. 
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5.3.3 Notification notifyChangedAlarm (O) 

IRP Agent notifies subscribed IRPManager regarding changes in e.g. perceived severity level in Alarm Information in 
Alarm List. The Alarm Information carried in the notification shall satisfy the current filter constraint of the 
subscription. 

The information carried in this notification contains all attributes that are filterable and are present in the original 
notifyNewAlarm. 

Table 8: Parameters of notifyChangedAlarm 



Name 


Qualifier 


Purpose 


notif icationHeader 


Input, M 


See Table 6: Notification Header 


alarmlnformationBody 


Input, M 


It contains information of the changed Alarm 
Information. See subclause 5.4.6 Alarm Information. 



5.3.4 Notification notifyAckStateChanged (M) 

IRP Agent notifies the subscribed IRPManager regarding changes in alarm Acknowledgement State in Alarm 
Information in Alarm List. The Alarm Information carried in the notification shall satisfy the current filter constraint of 
the subscription. 

If the alarm Acknowledgement State is changed to acknowledged, the Acknowledgement Information of the 
Alarm Information in Alarm List shall contain ackTime and ackState indicating "acknowledged". It may contain 
ackUserld and ackSystemld. The Alarm Information carried in the notification shall contain identical set of 
parameters as well. 

If the Acknowledgement State is changed to "unacknowledged", the Acknowledgement Information of the 
Alarm Information in the Alarm List shall be absent or shall contain no information. The Alarm Information carried in 
the notification shall have the Acknowledgement Information. It shall contain ackUserld, ackTime and 
ackState indicating unacknowledged. It may contain ackSystemld. 

The information carried in this notification contains all attributes that are filterable and are present in the original 
notifyNewAlarm. 

Table 9: Parameters of notifyAckStateChanged 



Name 


Qualifier 


Purpose 


notif icationHeader 


Input, M 


See Table 6: Notification Header 


alarmlnformationBody 


Input, M 


It contains the Alarm Information whose 

Acknowledgement State has changed. 
See subclause 5.4.6 Alarm Information. 



Subclause 6.1 specifies the Alarm States and some of these states relate to Acknowledgement State. 

5.3.5 Notification notifyClearedAlarm (M) 

IRP Agent notifies the subscribed IRPManager of alarm clearing if the subject Alarm Information satisfies the optional 
filter constraint expressed in the subscribe operation. 

IRP Agent shall remove the Alarm Information whose perceivedSeverity is cleared and its Acknowledgement 

State is "acknowledged'' from Alarm List. 

The information carried in this notification contains all attributes that are filterable and are present in the original 
notifyNewAlarm. 
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Table 10: Parameters for notif yClearedAlarm 



Name 


Qualifier 


Purpose 


notification 
Header 


Input, M 


See Table 6: Notification Header 


alarmlnformatio 
nBody 


Input, M 


It contains Alarm Information whose perceivedSeverityis 
cleared. Additionally, the Alarm Information may contain 
correlatedNotification (defined in 3GPP TS 32.106-2 [11]) 
that contains references to other Alarm Information whose 
perceivedSeverity levels are cleared as well. 
Alternatively, it contains an Alarm Information containing a 
correlatedNotification (defined in 3GPPTS 32.106-2 [11]) 
that contains references to other Alarm Information whose 
perceivedSeverity levels are cleared. 
See subclause 5.4.6 Alarm Information 



5.3.6 Notification notifyAlarmListRebuilt (M) 

IRP Agent maintains an Alarm List. If IRP Agent rebuilds this list for any reason, the IRP Agent shall notify 
IRPManager after the Alarm List is rebuilt. The conditions under which IRP Agent shall rebuild and the means by 
which IRP Agent shall rebuild its Alarm List are outside the scope of this IRP. 



Table 11: Parameters for notifyAlarmListRebuilt 



Name 


Qualifier 


Purpose 


notification 
Header 


Input, M 


See Table 6: Notification Header 


reason 


Input, M 


It provides Alarm List rebuilt reason. One valid reason is "indeterminate". 



5.4 



Behaviour 



5.4.1 Alarm List 

IRP Agent maintains an Alarm List. It contains all currently active alarms (i.e. Alarm Information whose 
perceivedSeverity is not Cleared) and alarms that are Cleared but not yet acknowledged. When an alarm is 
Cleared and is acknowledged, its corresponding Alarm Information in this Alarm List is removed. The removed Alarm 
Information shall no longer be accessible via this IRP. 

IRP Agent shall create a new Alarm Information in Alarm List whenever an alarm is emitted (internally within 
IRP Agent) that does not match with any alarm in the Alarm List. In this case, after the creation of the new Alarm 
Information, IRP Agent invokes not i f yNewAl arm operation. 

IRP Agent shall not create a new Alarm Information in Alarm List when an alarm is emitted (internally within 
IRP Agent) that matches with an alarm in the Alarm List. In this case, IRP Agent shall invoke either 

(1) notifyChangedAlarm or (2) notif yClearedAlarm followed by notif yNewAl arm operation. 

See Annex D for specification of alarm matching criterion. 

In the case of a matched Alarm Information and the change is the perceived Severity value, the following additional 
rule shall apply. 

IRP Agent shall remove all information in Acknowledgement Information of the subject Alarm Information. The 
Acknowledgement State shall be "unacknowledged". IRP Agent updates the eventTime and 
perceivedSeverity of the matched Alarm Information. IRP Agent invokes notifyChangedAlarm 
notification to all subscribed IRPManagers. 

5.4.2 Network Resource Name 

An alarm provides the alarm information of a specific network resource. Alarms use one parameter-attribute. Managed 
Object Instance (MOI), to identify the network resource. The semantics of MOI is defined in ITU-T Recommendation 
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X.720 [8]. The MOI shall be unique within a certain context, such as a transmission network or a switching network. 
This IRP does not specify the context. 

The encoding of MOI parameter-attribute value is SS dependent and is specified in ITU-T Recommendation X.720 [8] 
and 3GPPTS 32.106-8 [14]. 

5.4.3 Alarm Information Identification 

Since IRPManager can acknowledge and unacknowledge Alarm Informations currently kept in Alarm List of 

IRP Agent, there is a need to establish a convention so IRPManager and IRP Agent can unambiguously identify Alarm 

Informations in Alarm List. 

Since IRP Agent can generate notifications about the state change (e.g. perceivedSeverity level changes or 
Acknowledgement State changes) of an Alarm Information in Alarm List, there is a need to establish a 
convention so IRPManager and IRP Agent can unambiguously identify the Alarm Information whose state has changed. 

The convention, to identify Alarm Information, is the subject of this subclause. 

5.4.3.1 Use of alarmlnf ormationRef erence 

An alarmlnf ormationRef erence (AIR) unambiguously identifies one Alarm Information in IRP Agent's Alarm 
List. One IRP Agent has one Alarm List. The IRP Agent assigns AIR for the Alarm Informations in its own Alarm List. 

IRP Agent includes AIR in all notifications it emits. 

IRPManager shall include AIR(s) in acknowledge Alarms and unacknowledge Alarms. 

The mapping of AIR into its equivalents in respectively SS are done in Annex D. 



5.4.4 Alarm loss detection and recovery 



This IRP does not specify methods for IRPManager to detect alarm loss. The use of alarmld (see subclause 4.4.3.1) 
to detect alarm loss is an arrangement made between IRP Agent and IRPManager. This arrangement is outside the 
scope of this IRP. For example, IRP Agent may use integer sequence (e.g. 1, 2, 3, 4, 5. . .) as alarmlds for its alarms. 
Based on this knowledge, IRPManager can detect alarm loss. This kind of arrangement may not be possible for all SS. 

This IRP does not specify if IRP Agent can determine if IRPManager has received alarms correctly. Not all SSs provide 
such capability. 

This IRP does not specify methods for IRPManager and IRP Agent to recover alarm loss. The only mechanism 
recommended to deal with alarm loss is the use of getAlarmList operation. This IRP does not specify conditions 
under which IRPManager should invoke this operation. 

5.4.5 Alarm List loss 

IRP Agent can lose confidence in the integrity of its Alarm List. Under this condition, IRP Agent shall invoke 

not i f yAlarmLi s t Rebui It notification after it has successfully rebuilt the Alarm List. 

5.4.6 Alarm Information 

This subclause specifies the information contained in Alarm Information. 

Alarm Information(s) are stored in Alarm List. They are carried in not i f yNewAlarm, not i f yChangedAlarm, 
notifyAckStateChanged, notif yClearedAlarm. They are also carried in the response to 
getAlarmList operation. 

When it is carried in not i f yChangedAlarm notification, it indicates that one or more parameter-attribute values of 
the Alarm Information have changed since the most recent not i f yNewAlarm or not i f yChangedAlarm 
notification on the subject alarm. The following table identifies, using the symbol [Y] under "Qualifier" column, those 
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parameters-attributes whose value changes would trigger IRP Agent to invoke not i f yChangedAlarm or 

notifyAckStateChanged notification. 

When the alarm is carried in not if yChangedAlarm or notifyAckStateChanged notification, the following 
rule shall apply: 

• At least the value of one parameter-attribute marked with [Y] shall be different than that carried in the most 
recent notif yNewAlarm or not if yChangedAlarm of the subject alarm. 

Alarm Information, carried in notifications, always contain the AIR. In not if yNewAlarm, the AIR is used to 

identify the active Alarm Information carried in the notification. In not i f yChangedAlarm and 

not if yClearedAlarm, the AIR is used to identify the active Alarm Information whose state has changed. 

In not if yAckStateChangedAlarm, the AIR is used to identify the Alarm Information (active or inactive) in the 

Alarm List whose acknowledgement state has changed. 

Alarm Information contains the not if icat ionHeader and alarmlnf ormat ionBody. Table 6 defines 
parameter-attributes ofnotificationHeader. Table 1 3 defines the parameter-attributes of 

alarmlnf ormat ionBody. 

Letter M and O stands for Mandatory and Optional respectively. Letter Y identifies the parameter-attribute whose 
value changes would trigger IRP Agent to invoke not if yChangedAlarm or notifyAckStateChanged. 

Table 13: Parameter-Attributes of alarmlnf ormat ionBody 



Name 


Qualifier 


Comment 


probable 
Cause 


M 


It qualifies alarm and provides further information than event Type. See Annex B 
for a complete Hsting. This Hst is extensive. It is recommended that IRP Agent 
should use the list as is and not to extend it. It is noted that IRP Agent can privately 
(outside the scope of this IRP) define values for specif icProblem that provides 
semantics not conveyed by probableCause. A special probable cause value (SS 
specific, e.g. -1) indicates that this alternative is valid. This parameter-attribute 
value shall be single-value and of simple type such as integer or string. See 
definition in ITU-T Recommendation X.733 [2] subclause 8.1.2.1. 


perceived 
Severity 


M,Y 


It indicates the relative level of urgency for operator attention. . Legal values are 

Critical, Major, Minor, Warning, Indeterminate and 
Cleared, according to ITU-T Recommendation X.733 [2]. This IRP does not 
recommend the use of indeterminate. 


specific 
Problem 





It provides further qualification on the alarm than probableCause. This 
parameter-attribute value shall be single-value and of simple type such as integer or 
string. See definition in ITU-T Recommendation X.733 [2] subclause 8.1.2.2. 


correlated 
Notifications 





It identifies a set of notifications to which this notification is considered to be 
correlated. See definition in ITU-T Recommendation X.733 [2] subclause 8.1.2.9. 


backedUpStatu 
s 


0,Y 


It indicates if an object has a back up. See definition in ITU-T Recommendation 
X.733 [2] subclause 8.1.2.4. 


backUpOb ject 


0,Y 


It carries the DN of the back up object. It shall be absent if backUpStatus is absent 
or its value indicates false. See definition in ITU-T Recommendation X.733 [2] 
subclause 8.1.2.5. 


trend 
Indication 


0,Y 


It indicates if some observed condition is getting better, worse, or not changing. 
Legal values are "less severe", "no change" and "more severe". See definition in 
ITU-T Recommendation X.733 [2] subclause 8.1.2.6. 


threshold 
Info 


0,Y 


It indicates if the threshold crossed was in the up or down direction. See definition 
in ITU-T Recommendation X.733 [2] subclause 8.1.2.7. 


stateChange 
Definition 


0,Y 


It indicates MO attribute value changes. See definition in ITU-T Recommendation 
X.733 [2] subclause 8.1.2.10. 


monitored 
Attributes 


0,Y 


It indicates MO attributes whose value changes are being monitored. See definition 
in ITU-T Recommendation X.733 [2] subclause 8.1.2.11. 


proposed 

Repair 

Actions 


0,Y 


It indicates proposed repair actions. See definition in ITU-T Recommendation 
X.733 [2] subclause 8.1.2.12. 
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Name 


Qualifier 


Comment 


additional 
Text 


0, 


It provides the identity of the NE (e.g. RNC, Node-B) from which the alarm has 
been originated. It corresponds to the "user label" attribute of the MOC representing 
the NE in the Basic CM IRP Information Model. 
It can contain further information on the alarm. 


additional 
Information 


(see next 
column) 


It carries additional information related to the subject Alarm Information. It may 

contain the following parameter-attributes. 

Alarmld [ Y]: It identifies at most one Alarm Information in the Alarm List. See 

subclause 5.4.3.1. Use of this parameter-attribute is SS dependent. 

ackTime [Y]: It identifies the time of last operation acknowledgeAlarms or 

unacknowledgeAlarms. It is mandatory for notifyAckStateChanged, it 

is optional for other notifications. 

ackUserld [Y]: It identifies the last user who has change the 

Acknowledgement State via operation acknowledgeAlarms or 

unacknowledgeAlarms. It is mandatory for notifyAckStateChanged, it 

is optional for other notifications. 

ackSystemId [Y]: It identifies the system in which IRPManager, that invokes the 

acknowledgeAlarms or unacknowledgeAlarms operation, runs. It is 

optional for all notifications. 

ackState [Y]: It identifies the Acknowledgement State of the alarm. Its 

valid values are "acknowledged" and "unacknowledged". It is mandatory for 

notifyAckStateChanged, it is optional for other notifications. 
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Dynamic Model 



6.1 Alarm states 

Alarms have states. Figure 4 illustrates the alarm states. 

The triggers "MO emits. . ." are internal within IRP Agent and are not observable via the Alarm IRP. Other triggers, e.| 
"acknowledgeAlarms", are observable via the Alarm IRP. 

The solid circle icon represents the Start State. The double circle icon represents the End State. In this state, 
the alarm is cleared and acknowledged. The alarm shall not be accessible via the IRP and is removed from the Alarm 
List. 



MO emits changed 
ala[fm\ 



MO emits 
new alarm 



unack&unclear 



^ 



acknowledgeAlarms 



< 

^- unacknowledgeAlarms 

MO^mits changed alarm 



MO emits alarm cleared 



unack&clear 



acknowledgeAlarms 



^ 



ack&unclear 



MO emits alarm cleared 



ack&clear state. Alarm 
Information is no longer 
accessible via this IRP. 



Figure 4: Alarm States 
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Annex A (normative): 

Event Types and Extended Event Types 

This appendix lists and explains event types and extended event types used by Alarm IRP. 

Event type is carried by a parameter called event Type defined in 3GPP TS 32.106-2 [11]. 

Extended event types is acrried by a parameter called extendedEventType 3GPP TS 32.106-2 [11]. 

Encoding of event Type and extendedEventType is SS dependent. For example, the value of event Type 
can be encoded as Object Identifier in CMIP SS and as numeric string in CORBA SS. 

Table 14 and table 15 may be extended in the future. 

TableA.l: Event Types 



Event Types 



Explanation 



Communications Alarm 



An alarm of this type is associated with the procedure and/or process required conveying information from 
one point to another (ITU-T Recommendation X.733 [2]). 



Processing Error Alarm 



An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733 [2]). 



Environmental Alarm 



An alarm of this type is associated with a condition related to an enclosure in which the equipment resides 
(ITU-T Recommendation X.733 [2]). 



Quality of Service Alarm 



An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation 

X.733 [2]). 



Equipment Alarm 



An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733 [2]). 



Table A.2: Extended Event Types 



Extended Event Types 


Explanation 


New Alarm 


A notification of this type indicates that a new alarm has occurred. 


Changed Alarm 


A notification of this type indicates that one or more attributes, excepting those related to 
acknowledgement state, of an active alarm have changed. 


Acknowledgement State Changed 


A notification of this type indicates that the acnowledgement state of an alarm has changed. 


Cleared Alarm 


A notification of this type indicates that an alarm has been cleared and is no longer active. 


Alarm List Rebuilt 


A notification of this type indicates that the Alarm List has been succesfully rebuilt. 
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Annex B (normative): 
Probable Causes 



This appendix lists probable causes and their corresponding event types. 

Sources of these probable causes are ITU-T Recommendation M.3100 [9], ITU-T Recommendation X.721 [3], ITU-T 
Recommendation X.733 [2], ITU-T Recommendation X.736 [4] and GSM 12.11 [10]. 

The list may be extended in the future, e.g. with UMTS -specific probable causes. 

Table B.l: Probable Causes from ITU-T Recommendation M.3100 [9] 



M.3100 Probable cause 


Event type 


Indeterminate 


Unknown 


Alarm Indication Signal (AIS) 


Communications 


Call Setup Failure 


Communications 


Degraded Signal 


Communications 


Far End Receiver Failure (FERF) 


Communications 


Framing Error 


Communications 


Loss Of Frame (LOF) 


Communications 


Loss Of Pointer (LOP) 


Communications 


Loss Of Signal (LOS) 


Communications 


Payload Type Mismatch 


Communications 


Transmission Error 


Communications 


Remote Alarm Interface 


Communications 


Excessive Bit Error Rate (EBER) 


Communications 


Path Trace Mismatch 


Communications 


Unavailable 


Communications 


Signal Label Mismatch 


Communications 


Loss Of Multi Frame 


Communications 


Back Plane Failure 


Equipment 


Data Set Problem 


Equipment 


Equipment Identifier Duplication 


Equipment 


External IF Device Problem 


Equipment 


Line Card Problem 


Equipment 


Multiplexer Problem 


Equipment 


NE Identifier Duplication 


Equipment 


Power Problem 


Equipment 


Processor Problem 


Equipment 


Protection Path Failure 


Equipment 


Receiver Failure 


Equipment 


Replaceable Unit Missing 


Equipment 


Replaceable Unit Type Mismatch 


Equipment 


Synchronisation Source Mismatch 


Equipment 


Terminal Problem 


Equipment 


Timing Problem 


Equipment 


Transmitter Failure 


Equipment 


Trunk Card Problem 


Equipment 


Replaceable Unit Problem 


Equipment 


Air Compressor Failure 


Environmental 


Air Conditioning Failure 


Environmental 


Air Dryer Failure 


Environmental 


Battery Discharging 


Environmental 


Battery Failure 


Environmental 


Commercial Power Failure 


Environmental 


Cooling Fan Failure 


Environmental 


Engine Failure 


Environmental 


Fire Detector Failure 


Environmental 


Fuse Failure 


Environmental 


Generator Failure 


Environmental 


Low Battery Threshold 


Environmental 


Pump Failure 


Environmental 
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M.3100 Probable cause 



Event type 



Rectifier Failure 



Environmental 



Rectifier High Voltage 



Environmental 



Rectifier Low F Voltage 



Environmental 



Ventilation System Failure 



Environmental 



Enclosure Door Open 



Environmental 



Explosive Gas 



Environmental 



Fire 



Environmental 



Flood 



Environmental 



High Humidity 



Environmental 



High Temperature 



Environmental 



High Wind 



Environmental 



Ice Build Up 



Environmental 



Intrusion Detection 



Environmental 



Low Fuel 



Environmental 



Low Humidity 



Environmental 



Low Cable Pressure 



Environmental 



Low Temperature 



Environmental 



Low Water 



Environmental 



Smoke 



Environmental 



Toxic Gas 



Environmental 



Storage Capacity Problem 



Processing error 



Memory Mismatch 



Processing error 



Corrupt Data 



Processing error 



Out Of CPU Cycles 



Processing error 



Software Environment Problem 



Processing error 



Software Download Failure 



Processing error 



Table B.2: Probable Causes from ITU-T Recommendation X.721 [3] / ITU-T Recommendation X.733 [2] 



X.733 Probable Cause 


Event type 


Adapter Error 


Equipment 


Application Subsystem Failure 


Processing error 


Bandwidth Reduction 


Quality of service 


Call Establishment Error 


Communications 


Communication Protocol Error 


Communications 


Communication Subsystem Failure 


Communications 


Configuration or Customizing Error 


Processing error 


Congestion 


Quality of service 


Corrupt Data 


Processing error 


CPU Cycles Limit Exceeded 


Processing error 


Data Set or Modem Error 


Equipment 


Degraded Signal 


Communications 


DTE-DCE Interface Error 


Communications 


Enclosure Door Open 


Environmental 


Equipment Malfunction 


Equipment 


Excessive Vibration 


Environmental 


File Error 


Processing error 


Fire Detected 


Environmental 


Flood Detected 


Environmental 


Framing Error 


Communications 


Heating or Ventilation or Cooling System Problem 


Environmental 


Humidity Unacceptable 


Environmental 


Input/Output Device Error 


Equipment 


Input Device Error 


Equipment 


LAN Error 


Communications 


Leak Detection 


Environmental 


Local Node Transmission Error 


Communications 


Loss of Frame 


Communications 


Loss of Signal 


Communications 


Material Supply Exhausted 


Environmental 


Multiplexer Problem 


Equipment 


Out of Memory 


Processing error 


Output Device Error 


Equipment 


Performance Degraded 


Quality of service 
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X.733 Probable Cause 


Event type 


Power Problem 


Equipment 


Pressure Unacceptable 


Environmental 


Processor Problem 


Equipment 


Pump Failure 


Environmental 


Queue Size Exceeded 


Quality of service 


Receive Failure 


Equipment 


Receiver Failure 


Equipment 


Remote Node Transmission Error 


Communications 


Resource at or Nearing Capacity 


Quality of service 


Response Time Excessive 


Quality of service 


Re-transmission Rate Excessive 


Quality of service 


Software Error 


Processing error 


Software Program Abnormally Terminated 


Processing error 


Software Program Error 


Processing error 


Storage Capacity Problem 


Processing error 


Temperature Unacceptable 


Environmental 


Threshold Crossed 


Quality of service 


Timing Problem 


Equipment 


Toxic Leak Detected 


Environmental 


Transmit Failure 


Equipment 


Transmitter Failure 


Equipment 


Underlying Resource Unavailable 


Processing error 


Version Mismatch 


Processing error 



Table B.3: Probable Causes from GSM 12.11 [10] 



GSM 12.11 Probable Cause 


Event Type 


A-bis to BTS interface failure 


Equipment 


A-bis to TRX interface failure 


Equipment 


Antenna problem 


Equipment 


Battery breakdown 


Equipment 


Battery charging fault 


Equipment 


Clock synchronisation problem 


Equipment 


Combiner problem 


Equipment 


Disk problem 


Equipment 


Equipment failure 


Equipment 


Excessive receiver temperature 


Equipment 


Excessive transmitter output power 


Equipment 


Excessive transmitter temperature 


Equipment 


Frequency hopping degraded 


Equipment 


Frequency hopping failure 


Equipment 


Frequency redefinition failed 


Equipment 


Line interface failure 


Equipment 


Link failure 


Equipment 


Loss of synchronisation 


Equipment 


Lost redundancy 


Equipment 


Mains breakdown with battery back-up 


Equipment 


Mains breakdown without battery back-up 


Equipment 


Power supply failure 


Equipment 


Receiver antenna fault 


Equipment 


Receiver Failure 


Equipment 


Receiver multicoupler failure 


Equipment 


Reduced transmitter output power 


Equipment 


Signal quality evaluation fault 


Equipment 


Timeslot hardware failure 


Equipment 


Transceiver problem 


Equipment 


Transcoder problem 


Equipment 


Transcoder or rate adapter problem 


Equipment 


Transmitter antenna failure 


Equipment 


Transmitter antenna not adjusted 


Equipment 


Transmitter failure 


Equipment 


Transmitter low voltage or current 


Equipment 


Transmitter off frequency 


Equipment 
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GSM 12.11 Probable Cause 



Event Type 



Database inconsistency 



Processing error 



File system call unsuccessful 



Processing error 



Input parameter out of range 



Processing error 



Invalid parameter 



Processing error 



Invalid pointer 



Processing error 



Message not expected 



Processing error 



Message not initialised 



Processing error 



Message out of sequence 



Processing error 



System call unsuccessful 



Processing error 



Timeout expired 



Processing error 



Variable out of range 



Watch dog timer expired 
Cooling system failure 



Processing error 



Processing error 



"-^^^""^""to ^j^^vv.^^^ ^^^^^^^ 

External equipment failure 



Environmental 



Environmental 



External power supply failure 



Environmental 



External transmission device failure 



Environmental 



Fan failure 



Environmental 



High humidity 



Environmental 



High temperature 



Environmental 



Intrusion detected 



Environmental 



Low humidity 



Environmental 



Low temperature 



Environmental 



Smoke detected 



Environmental 



Excessive Error Rate 



Quality of service 



Reduced alarm reporting 



Quality of service 



Reduced event reporting 



Quality of service 



Reduced logging capability 



Quality of service 



System resources overload 



Quality of service 



Broadcast channel failure 



Communications 



Connection establishment error 



Communications 



Invalid message received 



Communications 



Invalid MSU received 



Communications 



LAPP link protocol failure 



Communications 



Local alarm indication 



Communications 



Remote alarm indication 



Communications 



Routing failure 



Communications 



SS7 protocol failure 



Communications 



Transmission error 



Communications 
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Table 20 identifies probable causes that are defined by more than one standard. This is for information only. 

Table B.4: Duplicated Probable Causes 



Duplicated Probable Cause 


GSM 12.11 


X.721 X.733 


M.3100 


Event Type 


Call Establishment Failure (X.721/X.733) 
Call Setup Failure (M.3100) 




X 


X 


Communications 


Degraded Signal 




X 


X 


Communications 


Framing Error 




X 


X 


Communications 


Loss of Frame 




X 


X 


Communications 


Loss of Signal 




X 


X 


Communications 


Equipment Failure (GSM 12.11) 
Equipment Malfunction (X.721/X.733) 


X 


X 




Equipment 


Multiplexer Problem 




X 


X 


Equipment 


Power Problem 




X 


X 


Equipment 


Processor Problem 




X 


X 


Equipment 


Receiver Failure 


X 


X 


X 


Equipment 


Timing Problem 




X 


X 


Equipment 


Transmitter Failure 


X 


X 


X 


Equipment 


Enclosure Door Open 




X 


X 


Environmental 


Fan Failure (GSM 12.11) 
Cooling Fan Failure (M.3100) 


X 




X 


Environmental 


Fire Detected (X.721/X.733) 
Fire (M.3100) 




X 


X 


Environmental 


Flood Detected (X.721/X.733) 
Flood (M.3100) 




X 


X 


Environmental 


High Humidity 


X 




X 


Environmental 


High Temperature 


X 




X 


Environmental 


Intrusion Detected (GSM 12.11) 
Intrusion Detection (X.736/M.3100) 


X 




X 


Environmental 


Low Humidity 


X 




X 


Environmental 


Low Temperature 


X 




X 


Environmental 


Pump Failure 




X 


X 


Environmental 


Smoke Detected (GSM 12.11) 
Smoke (M.3100) 


X 




X 


Environmental 


Storage Capacity Problem 




X 


X 


Processing Error 


Excessive Bit Error Rate (M.3100) 
Excessive Error Rate (GSM12.11) 


X 




X 




Corrupt Data 




X 


X 


Processing Error 
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Annex C (informative): 

Examples Use of notifyChangedAlarm 

This appendix describes a number of valid and invalid interactions governing the case when IRP Agent is reporting a 
specific fault of a particular network resource whose alarm severity level changes from, say critical to minor and then to 
Cleared. 

In the examples, ni is notif icationid, moc is managedOb jectClass, moi is managedObject Instance, 
et is eventType, pc is probableCause, sp is specif icProblem, ps is perceivedSeverity and ai is 
Alarmld. 



Valid sequence 1 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyChangedAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(3) NotifyClearedAlarm 

(ni=3, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

Valid sequence 2 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyClearedAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(3) NotifyNewAlarm 

(ni=3, ai=Y, moc=A^ moi=B, et=C, pc=D, sp=E, ps=Minor) 

(4) NotifyClearedAlarm 

(ni=4, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

Invalid sequence 1 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyChangedAlarm 

(ni=2, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(3) NotifyClearedAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 
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Interaction (2) is illegal since it uses a different ai for the same alarm. It should use ai=X as in interaction (1). 

Invalid sequence 2 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyNewAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

Interaction (2) is illegal since it invokes notify NewAlarm using same ai value. It should use 

notif yChangedAlarm with the same ai value. 
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Annex D (normative): 

Mapping of Alarm Information Reference to its Solution Set 

Equivalents 

This appendix specifies the mapping of AIR into its SS equivalents. It also specifies the conditions under which these 
attributes shall be used in the mapping process. 

Currently, there are two methods to map AIR into SS equivalents. One method is the use of 

managedObject Instance and notif icationid whose semantics are defined by ITU-T. The other method is 

the use of alarmld whose semantics is identical to AIR. 

Table 21 specifies how identification of Alarm Information is achieved, with and without the use of alarmld. 

Table D.l: AIR Mapping Process 





Alarmld is USed 


Alarmld is not USed 


Acknowledg 
eAlarm, 
unacknowle 
dgeAlarm 


IRPManager places value of alarmld of 
the received notif yNewAlarm or 
related notifyChangedAlarm or 
related notifyClearedAlarm (they 
shall have the same value) in AIRs of 
alarmlnformationReferenceList 
of this operation. 
IRPManager can place multiple values. 


IRPManager places values of 

managedOb jectlnstance and 

notif icationid of the received 

not if yNewAlarm notification in AIRs of 

alarmlnformationReferenceList of this 

operation. 

IRPManager can place multiple pairs of values. 


notifyNewA 
larm 


IRP Agent assignes a new alarmld for this 
notification. 

AIR is mapped to this alarmld. 

IRP Agent creates a new Alarm Information. 
This new Alarm Information is classified as 
active. 


IRP Agent assignes anew notificationid to this 
notification. 

AIR is mapped to the managedOb jectlnstance 
and the notificationid of this notification. 

IRP Agent creates a new Alarm Information. This new 
Alarm Information is classified as active. 


notif yChan 
gedAlarm 


IRP Agent uses the same alarmld of the 
related not if yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

IRP Agent shall not create a new Alarm 
Information. 


IRP Agent assignes anew notificationid to this 
notification. 

AIR is mapped to the matching-criteria-attributes 
(defined below) of this notification. The value of this 
set of attributes shall be identical to that of one active 
Alarm Information in the Alarm List. 

IRP Agent shall not create a new Alarm Information. 


notifyClea 
redAlarm 


IRP Agent uses the same alarmld of the 
related not if yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

The IRP Agent shall not create a new Alarm 
Information. 

IRP Agent cannot indicate alarm clearing of 
more than one Alarm Information. 


IRP Agent assignes a new notificationid to this 
notification. 

IRP Agent shall not create a new Alarm Information 

AIR is mapped to the matching-criteria-attributes of 
this notification. The value of this set of attributes 
shall be identical to that of one active Alarm 
Information in the Alarm List. Additionally (in the 
same notification), IRP Agent may use 
correlatedNotif ications to carry AIRs of 
other active Alarm Informations whose 
perceivedSeverity is now set to Cleared as well, 
(in accordance to ITU-T Recommendation X.733 [2]) 
or 
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IRP Agent shall use correlatedNotifications exclusively 
to carry AIRs of active Alarm Informations whose 
perceivedSeverity is now set to Cleared, (in accordance 
with ITU-T Recommendation Q821 [1]). 


notifyAckS 
tateChange 
d 


IRP Agent uses the same alarmld of the 
related not if yNewAlarm for the 
alarmld of this notification. 

AIR is mapped to this alarmld. 

The IRP Agent shall not create a new Alarm 

Information. 

IRP Agent cannot indicate 

Acknowledgement State change of more 

than one Alarm Information. 


IRPAgent assignes a new notif icationid to this 

notification . 

IRPAgent shall not create a new Alarm Information. 

AIR is mapped to the matching-criteria-attributes of 
this notification. The value of this set of attributes 
shall be identical to that of the active Alarm 
Information in the Alarm List. Additionally (in the 
same notification), IRPAgent may use 
correlatedNotifications to carry AIRs of 
other Alarm Informations whose 
Acknowledgement State has changed as well, 
(in accordance to irU-T Recommendation X.733 [2]) 
or 

IRPAgent shall use correlatedNotifications 
exclusively to carry AIRs of Alarm Informations 
whose Acknowledgement State has changed, 
(in accordance to ITU-T Recommendation Q821 [1]). 



D.1 Matching-Criteria-Attributes 



This subclause identifies attributes that are defined in ITU-T Recommendation X.733 [2] as the matching-criteria- 
attributes. The attributes are: 



• managedOb jectlnstance 

• eventType 

• probableCause 

• specif icProblem, if present 
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Annex E (informative): 
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